大志说编程

主题

大家好，我是大志。

前面几篇文章中，我们整理了 Agent 架构、提示词工程、工具调用、记忆管理和 RAG 等面试题。这些内容主要在讲如何搭建和开发一个 Agent 应用，但在项目真正落地之后，往往还要解决一些性能和成本问题，比如如何降低 Token 成本、如何优化 Agent 响应速度、如何定位 Agent 故障等。

这些问题也是面试官经常会考查的点。因此，本文系统地整理了 Agent 性能优化相关的高频面试题和详细答案。

另外，完整的 AI Agent 面试题文档也已经同步到了 aiflowline.cn，大家可以结合文章一起阅读。

1、如何降低 Agent 应用的 Token 成本？ ​

LLM 的 Token 消耗来自输入和输出，所以降低 Agent 应用的 Token 成本，本质上就是减少无效的输入和输出。

可以从以下几个方向进行优化：

  • 精简 System Prompt：去掉一些重复、无意义的提示词。规则校验不要写在提示词中，使用代码校验的成本更低。
  • 减少无关上下文：不要把所有的历史消息、文档都放到提示词中，只放与当前问题最相关的部分。
  • 会话摘要：当会话内容过长时，可以对早期的聊天内容进行摘要和压缩，再放入提示词中。
  • RAG Rerank 重排序：进行 RAG 检索时，会检索出数量较多的文档。可以通过 Rerank 重排序，找到最相关的文档片段并放入提示词，避免大量不相关的文本片段进入 Prompt。
  • 限制输出长度：如果只需要输出问题答案，就明确要求 LLM 只输出答案，不输出分析过程。
  • 不同模型处理不同任务：将复杂的分析和决策交给能力较强的 GPT、Claude 模型；对于分类、意图识别等简单需求，使用小参数模型即可。

2、如何提高 Agent 响应速度？ ​

Agent 的整个调用流程包括 LLM 调用、工具调用、RAG 检索等步骤，因此提高 Agent 响应速度主要可以从以下几个方面入手。

  • 意图识别

Agent 执行任务时，并非每个任务都需要执行所有流程。比如用户提问“你好，你是谁？”，这类简单问题直接交给 LLM 回答即可。因此，在用户提问后，要先判断用户意图。

image-20260716130952789

  • 减少提示词长度

输入的提示词越长，LLM 响应越慢，因此要精简提示词，减少无关的历史记忆和 RAG 文档。

  • 优先使用流式输出

这里的流式输出，不仅指 LLM 生成内容的流式返回，也包括流式展示记忆召回、工具调用、RAG 检索等过程，这样可以显著改善用户体验。

  • 工具并行执行

对于执行结果互不依赖的工具，可以并行调用来减少等待时间。

  • 热点数据缓存

缓存相同文本的 Embedding 向量、热点问题的 RAG 检索结果、长期记忆等信息。

  • 设置工具超时时间

调用外部工具是 Agent 响应速度慢的重要原因之一，因此一定要设置超时时间，不能无限期等待。

3、在 Agent 应用中，哪些部分可以使用缓存，如何设计缓存？ ​

在 Agent 应用中，可以缓存热点数据来提升响应速度，同时要分层设计缓存。

常见缓存如下：

  • 回答缓存：对于完全相同的提问，可以将最终答案进行缓存。
  • RAG 检索缓存：对相同问题进行 RAG 检索的结果可以缓存一段时间，尤其是针对热点问题。
  • Embedding 缓存：同一段文本通过 Embedding 生成的向量数据可以进行缓存，使用时直接取出。
  • 工具结果缓存：对于天气、汇率、商品等信息查询工具，可以对结果进行缓存，并根据业务设置合适的过期时间。
  • 用户画像缓存：用户偏好、组织信息等需要频繁读取的数据可以放入缓存中。

使用缓存时需要注意，在设计缓存 key 时，应按用户隔离私有数据。不同用户的权限、知识库数据和记忆数据有所不同，答案也会不同。此外，还要设置合适的缓存过期时间，避免出现数据污染。

4、如何监控 Agent 运行状态？ ​

在 Agent 运行过程中，不能只看接口请求是否成功，还要监控 Agent 的一些关键指标。

可以从以下层面对 Agent 进行监控：

  • 接口层：请求数量、成功率、错误率、平均响应时间。
  • LLM 层：LLM 调用次数、首个 Token 响应时间、LLM 总体响应时间、输入和输出 Token 数量。
  • 工具层：调用次数、成功率、重试次数、平均耗时、调用失败原因。
  • 业务层：任务完成率、用户点赞/点踩、转人工率。

在生产环境中，可以使用 Prometheus 和 Grafana 展示监控数据，使用 ELK 进行日志查询，使用 OpenTelemetry 采集完整的链路信息。在 LangChain 或 LangGraph 项目中，也可以使用 LangSmith 查看 LLM 调用、工具调用等节点的执行过程。

5、如何统计 Agent 的 Token 消耗？ ​

Agent 执行一次任务的过程中，可能会多次调用模型。因此，要计算一次任务使用的 Token 数量，需要统计每次 LLM 调用的用量并求和，得到最终消耗的总量。LLM 响应一般会返回本次调用的输入 Token、输出 Token 和总 Token 数量，因此可以在每次调用后记录这些 Token 信息。

之后再根据所用模型的输入 Token 单价和输出 Token 单价进行计算：

text
本次调用费用 = 输入 Token 数量 × 输入单价 + 输出 Token 数量 × 输出单价

现在大多数模型都支持缓存。如果命中缓存，就需要按照模型缓存命中的价格计算，最终得到实际花费金额。需要注意的是，本地的 Token 分词器适合用于费用估算，不适合直接用于账单计算，因为不同模型厂商的 Token 计算方法并不相同。

6、如何统计 Tool 调用成功率？ ​

统计 Tool 调用成功率时，要区分技术调用成功和业务调用成功。技术成功是指工具正常返回结果；业务成功是指不仅正常返回结果，还表示业务也执行成功，例如查询到指定订单、成功创建商品等。

Tool 调用成功率的基本计算方式如下：

text
Tool 技术成功率 = 技术成功次数 / 总调用次数 × 100%
Tool 业务成功率 = 业务成功次数 / 总调用次数 × 100%

比如一天调用天气查询工具 10000 次，成功 9900 次，失败 100 次，Tool 调用成功率就是 99%。

可以通过埋点、日志和统计系统来计算 Tool 调用成功率。每次工具调用完成后，生成一条如下的 Trace 信息：

json
{
  "trace_id": "trace_001",
  "tool_name": "search_docs",
  "success": true,
  "duration_ms": 320,
  "error_type": null,
  "retry_count": 0
}

然后通过 Prometheus 和 Grafana 进行指标监控，就可以完成对 Tool 调用成功率的监控。

7、如何定位 Agent 故障？ ​

Agent 出现故障通常涉及模型、Prompt、RAG、工具等多个环节。定位问题时，不能只关注报错信息，还要根据 trace_id 排查整条链路中出现的异常。

可以对下面的环节进行重点检查：

  • 用户输入：问题是否完整，是否缺少关键信息，或者有歧义。
  • Prompt：系统提示词是否正确，记忆信息和 RAG 文档是否与问题相关。
  • LLM 推理：LLM 是否选择了正确的工具，工具参数是否正确。
  • RAG 检索：文档是否被正常召回，检索出的文档 Chunk 的语义是否完整，重排序是否将最相关的内容排在前面。
  • 工具执行：工具执行是否超时或被限流，用户是否具有工具执行权限，工具调用是否因参数校验失败或接口异常而失败。
  • 状态流转：执行图运行时，是否进入错误的分支，是否重复执行同一个节点，是否超过最大步骤数。
  • 最终回答：LLM 是否正确使用工具执行结果和 RAG 检索结果，是否遗漏信息，是否出现幻觉。

定位到出错的环节后，再使用相同的问题、Prompt、LLM 和工具配置进行复现。不过，Agent 的输出具有较强的不确定性，可能需要多次执行，以判断是必现问题还是偶发问题。

8、如何做 Agent 链路追踪？ ​

在 Agent 应用中，链路追踪主要通过 Trace ID 和 Span 记录一次 Agent 的执行过程。首先，为一次用户请求生成唯一的 Trace ID；Agent 应用内部的各个步骤，如 LLM 调用、RAG 检索、工具调用和记忆召回，都会生成 Span。这样就可以清楚地查看整个执行过程，方便分析每个步骤的耗时并定位故障。

在 Span 中可以记录如下信息：

json
{
  "trace_id": "trace_001",
  "span_id": "span_002",
  "name": "search_docs",
  "type": "tool",
  "start_time": "...",
  "end_time": "...",
  "duration_ms": 320,
  "status": "success",
  "input": {},
  "output": {},
  "error": null
}

每个 Span 中需要记录一些关键信息，如 trace_id、span_id、名称、类型、开始时间、结束时间、耗时、是否成功、上下文信息和异常信息。LLM 调用还可以记录模型名称和 Token 用量；在 RAG 检索中，可以记录召回的文本片段 ID 和得分。

在实际项目中，可以使用 LangSmith 或 OpenTelemetry 实现链路追踪，并结合 Prometheus、Grafana 进行指标监控，用于定位 Agent 执行失败的原因，并进行性能分析。

如果项目使用 LangChain 或 LangGraph，可以为节点增加 Tracing Middleware，采集 LangGraph 每个节点的执行状态，并记录节点的输入、输出信息、耗时和异常信息。

9、如何处理模型不可用？ ​

在生产环境中，模型不可用可能由请求超时、API 限流、网络故障等原因引起。首先要设置超时时间和重试机制，重试可以解决短时间网络波动导致的模型不可用问题，但要限制重试次数，并使用 指数退避 和 随机抖动 策略进行重试。

其次是配置模型 Fallback。当主模型不可用时，自动切换到备用模型。如果同一个模型连续失败，则通过 熔断机制 停止继续调用该模型，避免故障扩大和请求堆积，同时进行降级，例如直接返回“当前应用暂时不可用，请稍后重试”。

最后，通过 Trace 记录错误类型、失败模型和错误信息，并使用 Metrics 监控 LLM 调用成功率、延迟时间和错误类型，以便及时发现并解决问题。

本期 Agent 性能优化面试题 就到这里。后面我会 每周至少更新 1 期面试题系列，想看后续 AI Agent 进阶面试题 的朋友，欢迎关注「大志说编程」！

觉得有用的话，转发给正在面试的小伙伴，咱们下期见~

最后更新于: